1. Field of the Invention
The present invention relates, generally, to an improved data processing system and, more specifically, to a computer-implemented method for correlating entities.
2. Description of the Related Art
Service-Oriented Architecture (SOA) allows applications and users to consume services provided by different parties, such as service providers and service requesters. Service requesters are applications or users that request services from a service provider. A service provider may be an application that exposes a service interface for requesters to use. Service-Oriented Architecture typically defines a coupling between service requesters and service providers as loosely coupled.
Service providers advertise their services using Web Service Definition Language (WSDL) files, which service requesters can look up. The web service definition language files may be hosted on the service provider's server or the web service definition language files may be hosted on a central Universal Description Discovery Integration (UDDI), (an industry standard available from OASIS at http://uddi.xml.org/), registry server. Services are generally intended to offer high-level business functions, such as a service to look up employee data. The web services are not intended to offer low-level services like requests to read a particular database record, or to execute a particular Structured Query Language (SQL) statement.
Service-Oriented Architecture presents many advantages to an implementing enterprise. Different organizations can easily expose new services for requesters to use, and because of the loose coupling between service requesters and service providers, it is easy for new services to be added and reused. It is also easy for requesters to use newly-created services, and/or existing services in new sequences, in order to support new business processes.
However, Service-Oriented Architecture also has to deal with data harmonization. Typically, business entities are represented and identified differently in different systems. For example, an employee number may identify an “employee” in a company's human resource system, whereas the same “person” is identified by an email address in an insurance system. The company human resource system may send a request to an insurance service provider to provide the policy coverage and renewal information for the person with employee number 1234. However, the insurance service provider may not be able to process this service request because the insurance company does not know its customers' employee numbers. The insurance company identifies its customer using a different identification scheme of email address.
Furthermore, it is envisioned that a service provider may in turn call other service providers as it services a service request. The technique is referred to as service composition. For example, the insurance service provider may contact a medical records system to obtain medical history information for the person in question before the insurance service provider responds to the human resource system's service request. The medical records system may identify each patient using the patient's driving license number, which is unknown to the insurance system.
A typical approach involves both organizations harmonizing respective data through a common shared understanding. For example, the human resource company and the insurance company agree to use a third identifier to identify their employees/customers. This approach requires that both databases in both organizations be updated with this common third field, and that all service requests between the organizations use the third field as the identifier for the employee/customers. However, in a Service-Oriented Architecture implementation, it is often difficult to know all the partner service providers during database setup time.
With loose coupling, the list of service partners is likely to change over time, causing increased management issues in maintaining the databases with all the common identifiers. Establishing a shared data understanding with each service provider also takes a lot of time, and makes it difficult to implement in a Service-Oriented Architecture implementation when service providers are constantly changing.
Another approach may be to install a translating hub between both organizations. The hubs are commonly referred to as enterprise application integration hubs or messaging hubs. The hubs allow data in a service request to be translated as the request is moved from the service requester to the service provider. For example, a translating hub may intercept all service requests from the human resource company to the insurance company, and replace employee numbers with email addresses. The data mapping may be created dynamically at run time, or through a pre-built database of mapping values. However, this solution approach usually requires that the hub be installed either with a neutral party, or with the requester or service provider.
As with the first approach described above, the loose coupling increases the management issues in many situations because a requester is expected to use different service providers over time, or may make use of multiple providers at one time. The setup and running of the hubs becomes a very expensive proposition because configurations keep changing.
In addition, the described methods typically do not support service composition very well. Service composition occurs when a service provider, of a first tier, calls another service, of a second tier, while fulfilling a service request. In these cases, the second tier service provider also needs correlation information to know which business entity the first tier service provider is referencing.
The current implementations generally require that either a prior understanding be established between the first tier and second tier providers, or a hub be installed between the first tier and second tier providers, with a link to the service requester.